The present invention relates to communication networks and more particularly to a communications protocol with improved security.
Much of the traffic on the Internet uses the Transmission Control Protocol, TCP. The details of TCP are specified in a document known as RFC793. Well-known Internet protocols and applications such as Telnet and HTTP rely on TCP to send and receive messages.
Security experts have known for years that TCP was vulnerable to various forms of abuse. In June, 1996, the on-line hacker magazine Phrack published a detailed discussion of the vulnerabilities of TCP. Starting Friday, Sep. 6th, 1996, saboteurs used some of these weaknesses to attack Public Access Networks Corporation. The company's nickname is PANIX. The attack was of the type called SYN Flooding, or a SYN Flood Attack, as will be discussed more below. The result of the attack was that users on the Internet were unable to fetch Web pages or other information from the PANIX servers. (This attack affected primarily the Web hosting component of PANIX's business, not the component that provides Internet access to consumers via modems.) The SYN Flood attack worked to the great detriment of the (roughly) 6000 individuals and 1000 companies who used PANIX to host their Web pages and other information. There is reason to believe that institutions other than PANIX have been attacked, but have chosen not to publicize the fact.
In simplest terms, the nature of a SYN Flood Attack is as follows: To set up a TCP connection between a client and a server, a series of three Internet Protocol (IP) messages should be exchanged. If the client reneges on the protocol in the middle of this exchange, there can easily arise a situation where the server has already committed considerable resources to the incipient connection, whereas the client has not. By sending (and reneging on) a vast number of TCP setup requests, a client (if it has relatively modest resources) can overload a server (even if it has relatively vast resources). Once a server is overloaded, the machine can no longer respond to legitimate connection requests.
A key element of this scenario is that under IP version 4 (IPv4, which is the basis of the current Internet), the part of an IP packet that identifies the sender (the source IP address) might (intentionally or otherwise) be incorrect. This is called IP spoofing. Because packets can be sent with an incorrect source IP address, it is very difficult to track down a client that is (maliciously or otherwise) violating the TCP protocol. This also makes it difficult to distinguish between attack packets and legitimate connection requests.
FIG. 1 is a state table which illustrates the basic three-way handshake for connection synchronization for TCP. In FIG. 1, client and server states are represented with three digit numbers (i.e., 10A, 20A, 30A), while transitions or steps performed between states are represented with five digit numbers (i.e., 1020A, 2030A). For example, step 1020A is the step performed between states 10A and 20A.
Referring to FIG. 1, in state 10A, the client is closed (no connection), while the server is listening for synchronization requests (a request to open a TCP connection). In step 1020A, the client sends a synchronization (SYN) message to the server with a request to open a TCP connection. The synchronization flag (SYN) is set to indicate that the three-way TCP connection handshake is in process (i.e., the two sides are synchronizing the TCP connection). Also, the client establishes the uplink (client to server) initial sequence number (100 in this example) in step 1020A. In state 20A, the server receives the SYN message from the client and goes into the SYN-RECEIVED state, while the client is in the SYN-sent state (indicating that the client has sent a SYN message).
Next, in step 2030A, the server sends a SYNACK message (both SYN and ACK flags are set) to the client, establishing the downlink (server to client) initial sequence number (300 in this example). Also, the acknowledgment number is set to 101, and the ACK and SYN flags are both set. Setting the SYN flag indicates that the TCP synchronization process is continuing. Setting the ACK flag to one indicates that the acknowledgment number is valid. The acknowledgment number of 101 in the SYNACK message of step 2030A acknowledges receipt from the client of the SYN message. (In general, an acknowledgment number acknowledges receipt of all messages having a sequence number less than the acknowledgment number.) The client then receives the SYNACK message sent from the server, and the connection is now established only on the client's side, state 30A.
In step 3040A, the client sends a message acknowledging receipt of the SYNACK message by setting the ACK flag and setting the acknowledgment number to 301. After these three messages have been transferred, the connection is fully established, state 40A. In step 4050A, the client sends data to the server.
In a SYN Flood attack, the attacking client sends a packet with the SYN flag set (just like step 1020A). The server sends the ordinary response, (i.e., a packet with the SYN and ACK flags set, step 2030A), but the client never responds with the ACK message (step 3040A). Indeed, in the typical case that the IP address specified in the original SYN message was bogus, the attacking client will never even receive the SYNACK message.
It can be assumed that in an attack packet, the source IP address corresponds neither to the attacker's machine nor to any other TCP-compliant machine. This is because if any other compliant machine were to receive the SYNACK message of step 2030, it would immediately respond by sending a reset (RST) message to the server, aborting the incipient connection and releasing the associated resources.
Ordinarily, when the server goes into the SYN-RECEIVED state, it allocates some amount of memory for the connection. At the very least, the server should remember that a SYN message was received with the given sequence number (100 in this example), and the client's IP address and port number. In addition, since the client can specify important option information in the option fields (OPT) of the SYN message, the server should also store the option information when possible.
One problem is that server implementations that do not take into account the possibility of a SYN Flood attack typically allocate not just the bare minimum amount of memory, but allocate in memory a full-blown Transmission Control Block after receiving a SYN message to store all the required information for the connection with the expectation that the incipient connection will soon become a fully-established connection. The damage done by a SYN flood attack grows linearly with the amount of memory allocated. Eventually, the incipient connection will time out, whereupon the allocated resources will be released. This means that the damage done by a SYN flood attack grows in proportion to the timeout parameter.
Several techniques have been proposed for defending against SYN Flooding. For example, there is an effort to deploy IP version 6 (IPv6) which may eliminate IP spoofing using public key encryption. On the other hand, the IPv6 solution is expected to require complex management of cryptologic keys. Furthermore, there are tens of millions of machines around the world that rely on the current IP (i.e., IPv4) and TCP specifications, and it is quite impractical to upgrade them in the short term. Therefore it is highly desirable to find defenses that operate effectively with existing IPv4/TCP clients and other protocols which may be vulnerable to a SYN Flood attack.
Because the attacking client needs to invest a slight amount of computation resources, a slight amount of communication resources, and zero memory storage resources, it is desirable to find a defense where the server commits only proportional amounts of resources, namely modest computation, modest communication, and, if at all possible, zero memory.
One defense to SYN flooding is known as the Syncookie method of Bernstein and Schenk (Bernstein/Schenk Syncookie method). FIG. 2 is a state table which illustrates the basic handshake for the Bernstein/Schenk Syncookie method. The Syncookie handshake of FIG. 2 is similar to the handshake of FIG. 1, except in FIG. 2, the server's Initial Sequence Number (generated for use in the SYNACK message at step 2030B) is represented by $c. The server's Initial Sequence Number ($c) is generated by the server as a cryptologic function (such as the MD5 message-digest algorithm or some other hash function) based upon the client's Initial Sequence Number (100 in this example), the client's IP address, and a secret known only to the server, among other things. Then in the simplest case, it is unnecessary for the server to store any information in memory (such as a client sequence number or source IP address) after receiving the SYN message of step 1, because when the server receives the message of step 3040B, the server can immediately check if the incoming acknowledgment number matches the appropriate hash function output. If a match is found, then the acknowledgment must have come in reply to a SYNACK message from this server, and the server can therefore trust the client and (after receiving the ACK message of step 3040B) allocate whatever resources will be needed by the connection, which can now be considered fully established.
The server's choice of $c is mildly restricted by the need to recognize and shut down half-open connections, such as arise when the server or client crashes while a connection is open between them. A more significant restriction is that the server's value for $c should encode, to a sufficient approximation, the source IP address and port number, and (if possible) all important information carried by the option (OPT) fields in the original SYN message. There are, however, limits on the number of bits that can be encoded using the Syncookie method. In practice this means that certain client-requested options the server would otherwise honor must be discarded under the Syncookie method because there is insufficient space (only 32 bits) available in the sequence number to encode the options.
The limited ability to encode and honor TCP options is a major drawback to the Syncookie method. There are several client-requested options which may be present in the TCP header which are important and should be implemented by the server. For example, the most common TCP option is to specify a maximum segment size (MSS). Clients can avoid segment fragmentation and thereby improve TCP circuit performance by letting the server know the largest segment size it is willing to accept. The Syncookie method makes some provision for handling the MSS option, but must make approximations.
An additional refinement has been proposed to the Syncookie method. A server may be under attack only sporadically. At times when it is not under attack, it can recognize this fact, and can respond normally, allocating memory after step receiving the SYN message of step 1020B (rather than waiting until after receiving the message of step 3040B), and honoring all options normally.
Matt Blaze and collaborators proposed a slightly different scheme involving cookies, i.e. having the server encode information in its Initial Sequence Number. One useful idea in their proposal is the idea of a Friends Table, i.e. a table in the server's memory that tabulates the IP address of clients that have been recently observed to be complying with important parts of the TCP protocol. Their proposal revolved around a five-step handshake which imposes a noticeable performance penalty relative to the traditional three-step handshake. Another drawback to Matt Blaze's proposal was the use of a timeout. Since TCP timeout intervals are typically long compared to Internet round-trip times, the use of the timeout imposes an additional performance penalty.
Therefore, there is a need for an improved protocol which provides protection against SYN Flooding and which is compatible with the current version of TCP/IP. In addition, there is a need for an improved protocol which allows the server flexibility to implement options even when under attack, and which imposes a shorter delay than provided by the prior art techniques.